VC consumption in the MARS architecture for IP Multicast over ATM

The Multicast Address Resolution Architecture (MARS, [GA96]) has been accepted by the Internet Engineering Task Force (IETF) as the solution for using IP multicast over ATM networks. This architecture is based on a client/server model. The MARS server maintains mappings between IP multicast addresses and the corresponding set of ATM addresses of hosts that are members of the IP group. This is possible as ATM hosts register their IP group memberships with the MARS server. An ATM network is referred to as a cluster, and the ATM interface on each cluster member is assigned an IP address such that the cluster forms a Logical IP subnet (LIS). An ATM host which needs to transmit data to an IP multicast group ‘X’ sends a request to the MARS server, and receives the set of ATM addresses of hosts that are members of group ‘X’ in response. The sender then transmits IP multicast data after setting up a point-to-multipoint Virtual Circuit (VC) with the group members as leaves. This is referred to as the VC Mesh approach as each sender maintains a separate point-to-multipoint VC to the group. In the Multicast Server approach, each sender uses an intermediate entity known as the Multicast Server (MCS) for forwarding data to group members. Thus each sender needs to open a VC to the MCS only, with the MCS maintaining a single point-to-multipoint VC to the group members. Each group member thus terminates a single VC (from the MCS) in the MCS case, as opposed to terminating a VC from each sender in the VC Mesh case. [TA96b] gives a qualitative comparison of the two approaches. We have implemented and experimented with a MARS-client and an MCS confirming to [GA96] and [TA96a], details of which are described in [TA96b]. We have also designed protocols for use of multiple MCSs per IP Multicast group, which are described in [TA96a] and [TA96]. This document focuses on the VC consumption resulting from use of the MARS architecture to support IP Multicast over ATM networks. VCs can be an expensive and scarce resource in an ATM network. Users may be billed on a per VC basis, in which case it is economically desirable to maintain a low VC count. VCs consume memory and other resources at end hosts, which places practical limits on the maximum number of VCs that can be used at an ATM interface. This limit is on the order of 1000 VCs for current generation ATM Network Interface Cards (NICs). Each additional VC also increases the signaling load that the switches have to support. Considering these reasons, it is important to design and use applications such that VC consumption is minimized, both at the end-hosts (because of ATM NIC limitations) and in the ATM network (to reduce the signaling load and resource usage). VC consumption also influences the capacity of a cluster to support IP multicast groups. In the first part of this document we compute, using a simple model, the upper bound on the number of groups that can be simultaneously supported in a cluster, and use it as an indicator of the efficacy of the VC Mesh or MCS approach in minimizing VC consumption. In the second part, we attempt to understand the implications of using the MARS architecture in an increasingly ATM-based Internet from the VC consumption perspective. We use the group dynamics of the current MBONE as measured using mlisten ([AA96]) and compute the VC consumption when the MBONE hosts are connected to an ATM-based Internet.